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Design  of  Che  VAX  Instrumentation  Package  (VIP) 

L.W.  Dowdy,  W.S.  Freeze,  B.G.'Labaw,  and  J.X.  Reed 

1 .  Introduc  tion 

This  report  describes  the  design  of  the  VAX  Instrumentation 
Package  (VIP).  The  targe t  mach ine  initially  is  the  VAX  iI/780  running 
under  the  Unix  operating  system  at  the  Computer  Science  Department  of 
the  University  of  Maryland. 

VIP  is  a  software  monitor  of  VAX  performance.  1 1  is  designed  as 
an  aid  for  system  monitoring,  system  tuning,  and  system  modeling.  For 
example,  VIP  monitors  the  request  rate  of  system  files.  If  the  request 
rate  of  a  particular  file  becomes  high,  the  system  may  be  "tuned"  by 
making  the  file  resident  in  main  memory.  Specific  parameters  of  die 
file  (e.g.,  the  average  number  of  words  transferred  per  file  request) 
may  be  used  in  a  queuing  network  model  of  the  system  to  predict  the 
performance  impact  of  making  the  file  resident  in  main  memory. 

A  major  motivation  for  VIP  is  collec  ting  parametric,  values  for., 
and  providing  validation  of,  system  models  of  the  VAX.  In  the  past  few 
ye’ars,  sophisticated  and  powerful  modeling  techniques  have  been 
developed  [1].  A  major  problem  in  the  application  of  these  techniques 
is  that  actual  systems  do  not  monitor  those  input  parameters  that  are 
necessary  for  the  application  of  the  modeling  techniques.  Fur  the’-mo re, 
these  modeling  techniques  typically  provide  performance  measures  which 
are  more  extensive  than  are  usually  measured.  Validation,  as  well  as 
the  construction,  of  accurate  models  is  thus  a  difficult  problem. 

During  the  design  process  of  VIP,  several  existing  software 
monitors  were  examined  in  detail.  VIP  includes,  extends,  and  deletes 
several  of  the  ideas  from  these  existing  monitors.  The  specific 
monitors  examined  include: 

Univac  SIP  [2] 

VAX  VMS  Display  Utility  [3) 

Burroughs  SPARK  [4] 

IBM  RMF/SMF  [5] 

Tandem  XRAY  [6]  A1R  F0RC£  OFFICE  OF  SCIENTIFIC  RESEARCH  (AFSC) 
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Figure  1:  VIP  Structure 


A  user  initiates  VIP.  The  user  can  specify  various  options. 
These  options  include:  a)  the  specific  performance  information  desired, 
b)  the  specific  process  type(s)  (e.g.,  batch,  system  overhead,  Fortran) 
that  the  user  desires  to  monitor,  and  c)  timing  information  describing 
the  resolution  and  the  length  of  the  monitoring  session.  For  example,  a 
user  may  request  cpu  and  disk,  utilizations  (i.e.,  option  a),  for  small 
batch  jobs  (i.e.,  option  b) ,  to  be  reported  over  a  30  minute  period  in  5 
minute  intervals  (i.e.,  option  c).  VIP  monitors  the  requested  activity 
and,  according  to  user  specified  timing  resolutions,  logs  the 
information  on  secondary  storage.  Concurrently,  or  at  some  later  time, 
the  logged  information  is  used  by  a  data  reduction  program,  DRP,  which 
analyzes  the  data  and  produces  reports  for  the  user.  Upon  receiving 
initial  reports,  the  user  can  dynamically  alter  the  parameters  used  by 
VIP.  Since  the  timing  input  parameters  and/or  the  monitored  events  can 
be  changed,  the  overhead  of  cunning  VIP  on  the  system  is  variable. 

Section  2  of  this  report  specifies  the  data  structures  used  by  VIP 
in  recording  the  measurement  information.  Section  3  gives  the  specific 
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measured  entities 


2.  Da  ta  S  true  tur  es 
2. i  Record  Types 

To  record  information,  VIP  accesses  one  of  four  types  of  data 
structures.  The  data  structures  associated  with  a  measurable  entity 
depend  on  its  nature  and  the  desired  level  of  information  to  be 
acquired. 

The  four  types  of  data  structures  are  (see  Figure  2):  . 


Q-Dimension-Gric 


-  l-Dirension-Grid 


LOO 


Figure  2:  Data  Structure  Types 


A.  0-D  imens  lon-Gr  id  :  A  0-d  unens  ion-gr  id  record 


is  a  single 


coun  ter. 


It  holds  a  count  of  the  number  or  occurences  of  an 
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event  (e.g.,  number  of  page  faults). 

B.  1-D  , imens  ion-Gr  id  :  A  1-d  imens  ion-grid  record  is  an  array  of 
single  counters.  The  particular  counter  into  wh 'oh  an  event  is 
recorded  depends  upon  the  specific  measured  quantity.  For 
example,  consider  the  number  of  words  transferred  per  1/0 
request  to  a  disk..  The  number  of  I/O  requests  transferring, 
say  1  to  100  words  might  be  recorded  in  1-d  .imens  ion-gr  id  [  1  ] ; 
the  number  of  I/O  requests  transferring  101  to  200  words  might 
be  recorded  in  l-dimension-grid[2]  ;  and  so  on.  In  this  way  the 
distribution  of  the  event  is  recorded.  Device  service  time 
distributions  and  queue  length  distributions  can  be  obtained 
using  this  data  structure.  The  number  of  counters  and  the 
ranges  associated  with  each  counter  are  user  definable. 

C.  2-Dimension-Grid:  A  2-d  .imens  ion-gr  id  record  is  an  extension 

of  the  1-d  imens  ion-grid  record.  The  user  can  specify  the 
meaning  of  each  d.imens ion's  range.  For  example,  suppose  load 
dependent  service  time  distributions  are  desired  of  a  disk 
channel.  That  is,  the  average  time  it  takes  to  satisfy  a  disk 
request  (i.e.,  service  time)  depends  upon  the  number  of 
requests  in  the  disk  channel  queue.  This  dependency  may  be 
measured.  When  the  queue  has  more  than  1  request  presen  c,  the 
average  service  time  per  request  may  be  lower  since  seek 
activity  on  different  disk  units  may  overlap.  The  user  may 
specify  the  first  dimension  range  to  be  associated  with  the 
channel  queue  length  and  the  second  dimension  range  to  be 
associated  with  the  specific  measured  quanticy. 

2-d  .imens  ion-gr  id{  1 , 1  ]  might  record  the  number  of  service 

requests  which  require  0  to  5  msec  of  service  when  1  to  3 
requests  were  in  the  queue;  2-d  .imens  ion-gr  id  [  1 , 2  j  might  record 
the  number  of  service  requests  which  require  3  to  10  msec  of 
service  when  1  to  3  requests  wore  in  the  queue; 

2-u  imens  ion-gr  id  [  2 , 1 1  might  record  the  number  of  serv.v-3 
requests  which  require  0  to  3  msec  of  service  when  4  to  o 

requests  were  in  the  queue;  2-d  imens  to  n-gr  id  '  2 , 2 1  might  record 
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the  number  of  service  requests  which  require  5  to  10  msec  of 
service  when  4  to  6  requests  were  in  the  queue;  and  so  on  (see 
Figure  3).  In  this  way  the  relative  dependence  of  one 
measurable  quantity  parameter  of  an  event  to  ar.o  ther  measurable 
quantity  parameter  is  obtained. 


D.  Log  -  A  log  record  is  used  when  none  of  the  other  data 
structures  is  appropriate  to  record  the  occurence  of  an  event. 
This  is  the  case  when  the  number  of  parameters  measured  at  the 
time  of  an  event  is  too  great  to  be  recorded  in  the  other  data 
structures.  A  log  record  is  identified  with  a  single 
occurrence  of  an  event.  Specific  errors  in  the  system  may  be 
recorded  in  this  way. 


channel  service  time  (msec) 


0-5  5-10 


1-3 

channel 
que  ue 
length 


Figure  3:  2-Dimens  ion-Gr  id  Example 


2.2  Special  Job  Class  Monitoring 

A  value  of  i  or  0,  respectively,  is  assigned  to  a  process  to 
indicate  whether  or  not  the  process  is  singled  out  for  special 
monitor ing.  VIP  records  the  measurement  according  to  this  process  type. 
For  example,  the  count  of  the  number  of  disk  operations  might  ne  broken 
into  two  parts:  the  first  corresponding  to  processes  associated  with 


6 


1 


A 


student  jobs  and  the  second  to  all  other  processes.  Processes  which 
might  be  singled  out  for  special  monitoring  include:  batch  job 
processes,  processes  associated  with  jobs  having  a  certain  account 
number  range,  processes  using  a  certain  piece  of  so: tware.  User 
selection  of  singled  out  processes  may  be  done  dynamically. 


2. 3  Record  Descrip  tions 

2.3.1  O-Dimension-Gr  id 

A  0-dime  ns  ion-grid  record  contains  the  number  of  tirne^  an  event 
occurred  and  information  about  the  event  itself. 

Forma  t: 

Type 

0 -d  ime ns  ion-gr  id  =  record 


idnumber 

:  in  teger; 

1  eng  th 

:  integer; 

log  time 

:  in  teg  er ; 

0-grid 

: array [0. .  1  ] 

of 

in  teger; 

cum  to  t 

: array(0. . 1 ] 

of 

in  teger; 

s  tar  ttime 

: array [ 0. .  1  ] 

of 

in  teger; 

end; 

Expl ana  tio  n: 

idnumber  -  Event  identifier, 
length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

0~3rid  -  0-grid[il  holds  the  number  of  times  the  event  occurred  by- 
processes  with  type  i  for  1  =  0  or  1. 


cum  tot  —  cuatot[i]  holds  the  cumulative  total  of  the  measurement 
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values  ( i.  e.  ,  the  actual  quantities  measured  by  VIP) 
associated  with  processes  of  type  i  for  i  =  0  or  i.  -or 
example,  to  determine  the  .■•noun  t  of  tine  that  a  channel  ?.s 
idle  while  a  connected  device  is  bus;-  ( e.g.  ,  seeking), 
cumtot[lJ  would  hold  this  cumulative  tune  for  type  i 
processes,  while  cumtot[0]  holds  the  same  for  all  other 
processes.  In  contrast,  0-grid[i]  would  contain  tine 
number  of  times  that  the  channel,  is  idle  while  the  device 
is  busy  for  type  i  processes. 


starttime  -  starttimefi] 
record  by  a  type 


holds  the 
i  process. 


1  as  t 


time  VIP  accessed 


tiie 


Ex  am  pi  e: 

A  O-dimension-grid  record  might  be  used  to  record  disk  busy  times. 
VIP  accesses  the  record  whenever  a  disk  request  is  initiated  or 
terminated.  For  an  initiation,  the  s  farttime  is  simply  recorded.  For  a 
termination,  the  recorded  startc.ime  is  subtracted  from  the  current  time 
to  give  the  busy  time.  This  number  is  then  added  to  cumtot,  and  0-grid 
is  incremented  by  one.  The  average  busy  time  per  request  can  later  be 
calculated  by  the  Dll?  by  dividing  cumtot  by  0-grid. 


2.3.2  i-Dimens  ion-Cr  id 

A  1-dimension-grid  record  is  an  extension  of  a  0-d  .imens  ion-gr  id 
record  used  for  capturing  information  needed  to  determine  distributions. 
The  1-d imenson-gr id  record  contains  several  counters,  each  associated 
with  a  range  (user  definable).  A  counter  is  incremented  for  any  event 
occurrence  having  a  measurement  value  falling  in  its  given  range. 

Forma  t: 


1 -d  imens  ion-gr  id  =  record 


id  number 
ieng  til 
i  og  t  cm  e 


in  tever; 
in  teg  e  r ; 
in  teger; 


I 

! 


A 


i 


s  ize 

:  in  teger ; 

rangeid 

: in  teger; 

range 

:  arr ay[0. ,s ize-1 

]  of  in t 

1-grid 

: array ( 0. . 1 , 

0. . 

s  iz e ]  of 

cum  to  t 

: array [0. . 1 ] 

of 

in  teger; 

s  tar  ttime 

: array [0. . 1 ] 

of 

in teger; 

end ; 

Explanation: 

idnumber  -  Event  identifier. 

length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

size  -  The  number  of  counters  in  the  record. 

rangeid  •  Identifying  number  for  the  interpretation  of  the  range. 

range  -  Array  containing  the  boundary  limits  associated  with  the 
coun  ters . 

1-grid  -  An  array  of  counters.  The  first  subscript  refers  to  the 
process  type.  For  example,  1  — g  r  id  [  0 , 4  ]  counts,  for 
processes  with  type  0,  the  event  occurrences  having 
measurement  values  specified  by  the  range  boundaries  given 
in  range[3]  and  range[4], 

cum  tot  -  cum  to  t[  i]  holds  the  cumulative  total  of  the  measurement 
values  associated  with  processes  of  type  i  for  i  =  0  or  1. 

starttime  -  starttime[i]  holds  the  last  time  VIP  accessed  the 
record  of  a  type  i  process. 


Exampl e: 


A  1-dimension-grid  record  mighc  be  used  to  record  information 
ultimately  used  to  compute  the  average  and  distribution  of  CPU  burst 
times.  The  rangeid  would  specify  that  the  range  values  correspond  to 
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CPU  burst;  times.  The  array  range  might  .'.on  tain: 

r  ang  e  =  [  3  5  7  9  ...  j 

VIP  accesses  the  record  upon  each  CP!’  context  switch.  The  CrU 
burst  time  is  calculated  by  subtracting  starttime  from,  the  current  time. 
Suppose  batch  processes  have  been  singled  out  for  special  monitoring 
(i.  e.  ,  type  1).  For  a  batch  process  having  a  measured  burst  time  of  8 
ms,  the  number  8  is  added  to  cumtot[l]  (1  for  a  batch  process  type),  and 
I-grid[l,3]  is  incremented  by  one  since  range[2]  <  8  <_  range[3].  The 
average  batch  process  burst  time  can  later  be  calculated  by  the  DRP  by 
dividing  cum  to  t(  1  ]  by  the  total  count  which  is  found  by  summing 
1  -g  r  id  [  1 ,  k  ]  for  k  =  0..size. 

2.3.3  2-Dimension-Grid 

A  2-dimension-grid  record  is  an  extension  of  a  1-d  bens  ion-o  r  id 
record  used  for  capturing  information  needed  to  determine  distributions 
where  the  distribution  depends  upon  some  net-work  parameter.  The  record 
contains  several  counters.  When  an  event  occurs  the  specific  counter 
which  is  updated  depends  upon:  l)  the  process  type  associated  with  the 
event  and  2)  the  values  of  the  two  parameters  specified  by  rangexd  (user 
def  .inable) . 


Forma  t: 


2-dimension-grid  =  record 


id  number 

:  in  teger ; 

1  eng  th 

: in  teger ; 

log  time 

: in  teger; 

s  ize 

: array[0. . 1] 

of  integer 

range  id 

: array [0. . 1 J 

of  integer 

r angeO 

:array[0. .s ize[0]-I )  cf 

r  ang  e 1 

: array[0. .s ize[ I ]-l ]  of 

2-g  r  id 

: array[0. . 1 , 

0 .  .  s  iz  e  [  0  ] 

cum  to  t 

: array[0. . 1 , 

0 . .  s  i  z  e  [  0 1 

s  tar  ttime 

: array [u. . 1 j 

of  integer 

end : 

or  integer: 
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Expl  ana  Cion: 


idnumber  -  Event  identifier. 

length  -  The  record  length  in  words. 

log  time  -  The  time  the  record  was  last  logged  to  secondary  storage 
and  reinitialized. 

size  -  Array  containing  the  number  of  counters  in  the  record  in 
each  dimension. 

rangeid  -  Array  containing  identifying  numbers  for  the 

interpretation  of  the  range  in  each  dimension. 

rangeO  and  rangel  -  Arrays  containing  the  boundary  limits 

associated  with  the  counters  in  each  dimension. 

2-grid  -  An  array  of  counters.  The  first  subscript  refers  to  the 
process  type.  The  remaining  subscripts  refer  to 

respective  rangeid  interpretations.  For  example, 

2-gr id[ i, j ,k]  counts,  for  processes  of  type  i,  the  event 
occurences  having  measurement  values  specified  by:  1)  the 
range  boundaries  given  in  rangeO [j-1]  and  range0[jj  for 
the  first  dimension,  and  2)  the  range  boundaries  given  in 
rangel[k-l]  and  rangel(k]  for  die  second  dimension. 

cum  to  t  -  Array  of  cumulative  totals.  The  first  subscript  refers  to 
the  process  type.  The  second  subscript  refers  to  the 
first  dimension  range.  For  example,  cumtot[i,j]  holds  Che 
cumulative  total  of  measurement  values  associated  with 
processes  of  type  i  whose  first  dimension  interpretation 
is  bounded  by  range0[j-i]  and  range0[j]. 

starttime  -  s  tar  ttime[  i]  holds  the  last  time  VIP  accessed  the 
record  of  a  type  i  process. 
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Example: 

Suppose  the  In  ter  arr  ival  time  distribution  of  requests  to  the 
swapping  disk  is  desired.  However,  it  might  be  suspected  that  the 
distribution  depends  upon  the  number  of  processes  resident  in  main 
memory.  A  2-d  linens  ion-grid  record  could  be  used  as  follows. 

size  =  [3  4] 

range.id[OJ  =  "number  of  processes  in  main  memory" 
rangeid[l]  =  “  inter  arrival  times  to  the  swapping  disk." 
rangeO  =  [3  6  9] 

rang el  =  [5  10  15  20] 

Suppose  a  type  0  process  makes  a  request  for  the  disk  and  this 
2-dlmens  ion-grid  record  is  accessed.  The  value  of  s  tar  ttime[0j  in  the 
record  is  subtracted  from  the  current  time  and  this  difference  is  taken 
as  the  measurement  value.  The  value  of  starttime[0]  is  updated  to  the 
current  time  for  the  next  access.  Suppose  that  a  measurement  value  of 
22  msec  is  observed.  Suppose  that  the  number  of  processes  in  main 
memory  is  8.  The  counter,  2-grid[0,2,4]  ,  would  be  incremented,  since  0 
is  the  process  type;  range0[l]  <  8  £  range0[2];  and,  rangel[4j  <  22. 
The  measurement  value,  22,  would  be  added  to  cumtot[0,2],  since  0  is  the 
process  type  and  rangeO] 1}  <  8  £  rangeD[2]. 

The  average  interarrival  time  of  type  i  processes  to  the  swapping 
disk  when  k  processes  are  resident  in  main  memory  can  be  calculated  by 
the  data  reduction  program.  This  average  time  is  found  by  dividing 
cumtot[0,x]  by  the  sum  of  2-gr  id  [0  ,x  ,y  ]  ,  where  rangeOlx-1]  <  k  _< 
range0[x] ,  and  y  =  0,1, 2, 3, 4. 


2. 3. 4  Log 

A  log  record  is  specific  to  a  certain  event  and  is  created  by  VIP 


and  then  saved. 
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Forma  t: 

Type  log 


record 
id  number 
leng  th 
log  time 
proc  type 
res  t 
end; 


:  in  teg  er ; 

:  integer; 

: in  teger; 

:  in  teger; 

:o  therinfo; 


Expl  ana  tion: 

idnumber  -  Event  identifier, 
length  -  The  record  length  in  words, 

log  time  -  The  time  the  record  was  logged  to  secondary  storage. 

proctype  -  Holds  a  value  of  1  or  0  indicating  the  process  type  of 
the  process  causing  the  event. 

rest  -  (Whatever  event  specific  information  that  is  necessary). 


Exampl  e: 

A  log  record  might  be  used  to  gather  information  about  individual 
jobs  in  the  system.  The  record  would  contain  fields  for  the  creator  and 
creation  time  of  the  job. 

3.  Ins  trumentation  Entities 

This  section  details  the  individual  items  to  be  measured.  The 
type  of  data  structure  format  used  to  record  the  information  (described 
in  detail  in  the  previous  section)  is  given  for  each  item.  Certain 
measurements  can  be  derived  from  other  more  basic  measurements  (e.g., 
utilization  =  active  time/ total  time).  These  Items  3re  to  be  obtained 
from  the  data  reduction  program,  UUP,  and  are  so  indicated. 

The  individual  items  are  classified  into:  a)  I/O  devices,  b)  I/O 
controllers,  c)  terminal  interfaces,  d)  bus  resources,  e)  CPU  resources. 
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f)  memory  resources,  and  g)  software  resources. 


item 


data  s  true  tore 


a)  I/O  devices  (e.g. ,  RP06  disks,  TE16  tapes ,  DR  1  I  parallel  interfaces) 


1) 

number  of  words  transferred  in  and  out 

1-gr  id 

2) 

number  of  calls  (i.e.,  transfers,  transactions) 

DRP 

3) 

throughput  (i.e.,  calls  per  unit  time) 

DRP 

4) 

busy  (i.e.,  active)  time 

0-gr  id 

5) 

u  tiliza  tion 

DRP 

6) 

seek  time 

1-gr  id 

7) 

rotational  latency  time 

1-gr  id 

8) 

transfer  time 

1-grid 

,9) 

queue  length 

1-grid 

10) 

response  time  per  request  (i.e.,  queue  time  + 

service  time) 

:-g  r  id 

ID 

blocked  (i.e.,  device  idle  but  queue  is  nonempty) 

.  2-grid 

12) 

in  ter  arrival  time 

2-grid 

13) 

interdepar cure  time 

2-g  r id 

b)  I/O  controllers  (i.e.,  when  more  than  1  device  has  a  common 
controller) 


1)  number  of  words  transferred 

2)  number  of  calls 

3)  throughput 

4 )  busy  time 

5)  utilization 

6)  queue  length 

7)  response  time 

8)  controller  free  while  device  busy 

9)  controller  busy  while  device  free 

10)  device  overlap 

11)  blocked  (i.e.,  controller  idle  but  queue  is  nonaap  tv) 

12)  interarrival  time 

13)  interdepar  hire  time 


DRP 

DRP 

DRP 

0-grid 

DRP 

l~grid 
2-gr:,d 
0-grid 
0-gr  id 
2-grid 
2-gr-d 
2-gr  id 
2-g  r  id 


c)  terminal  interfaces  (e.g.,  DZ1I  multiplexors) 


1)  number  of  words  transferred 

2)  number  of  calls  (i.e.,  process  wakeups) 

3)  throughput 

4)  busy  time 

5)  utilization 

6)  queue  length 

7)  think  time  from  terminals 

8)  response  time  from  system 

9)  number  of  active  terminals 

10)  blocked 

11)  in  ter  arrival  time 

12)  interdeparture  time 


1-grid 

DRP 

DRP 

0-grid 

DRP 

l-grid 
1-gr  id 
1-grid 

1- gr  id 

2- gr  id 
2-grid 
2-gr id 


d)  bus  resources  (e.g.,  UNIBUS,  MASSBUS,  SBI,  console) 


1)  number  of  words  transrerred 

2)  number  of  calls 

3)  throughput 
4}  busy  time 

5)  utilization 

6)  queue  length 

7)  response  t.ime 

8)  bus  free  while  m.ic  busy 

9)  bus  busy  while  unit  free 

10)  blocked 

11)  in  ter  arrival  time 

12)  interdeparture  time 


i  r  id 

DRP 

DKP 

0-g  r  id 
DR? 


e)  CPU  resources  (by  processor  mode) 


1)  burst  time  distribution 

2)  number  of  bursts 

3)  throughput 

4 )  u  t  il  iz  a  tio  n 

5)  queue  length 

6)  response  time 

7)  number  of  interrupts  (by  type) 

8)  overhead  burst  time  distribution 

9)  overhead  number  of  bursts 

10)  overhead  utilization 

11)  monitor  overhead  time 

12)  monitor  overhead  utilization 

13)  blocked 

14)  in  ter  arrival  time 

15)  interdeparture  time 


1  -g  r  id 
DR? 

D..P 

DR? 


^-gr  id 
l~gr  id 
DRP 
DRP 

0-gr  id 
DRP 

2~gr  id 
2~gr  ic 
2 -grid 


f)  memory  resources 


1)  multiprogramming  level  (  i.  e.  ,  number  of  active  PCHs) 

2)  amount  ol  utilized  core 

3)  amount  of  available  core 

4)  active  time  of  memory  box  0 

5)  active  time  of  memory  box  1 

6)  active  time  of  both  memory  boxes  simultaneously 

7)  utilization  of  memory  box  0 

8)  utilization  of  memory  box  1 

9)  utilization  of  both  memory  boxes  simultaneously 

10)  working  set  size 

11)  free  page  list  size 

12)  page  pool  size 

13)  number  of  dirty  pages  ( t.  e.  ,  modify  list  size) 

14)  number  of  page  faults 

15)  program  size 

16)  page  cache  hit  ratio 

17)  swap  size  distribution 

18)  number  of  swaps 

19)  percentage  of  program  residency 

20)  page  1  ife  time 

21)  number  of  page  reads 

22)  number  of  page  writes 

23)  in  ter  arrival  time 

24)  interdeparture  time 


l  — g  r  ui 
:  r  Vu 

DR? 

0-g rid 
0-g  r  ia 
C-gr  id 
DRP 
DRP 
DP»P 
1  ~g  r  id 
1-grid 
1-gr  id 
0-g  rid 
0-gr  id 
1-gr  id 
0~gr  id 
1-gr  id 
DRP 
1  -g  r  id 

1- grid 
0-g  r  id 
C-gr  id 

2- gr  id 
2-grin 


g)  software  resources  (  i.  e. ,  any  queue  for  software)  (e.f 
schedulers,  I/O  files,  loaders,  exception  handlers,  Oi 


. ,  alloca  tors  , 
serv  ices) 


*5  * 

4< 

5) 

6) 
7) 

?! 


number  of  calls 
throughpu  t 
busy  time 
u  til  iza  tion 
queue  length 
response  time 

blocked  (  i.  e.  ,  queue  nonempty 
is  idle) 
inter  arrival  time 
interdeparture  time 


but  software  resource 


0-gr  id 
DHP 

0~gr id 
DR? 

1- gr  id 

2- g  r  id 

2-grid 
2-8  r  id 
2-g  r  id 


4.  Summary 

A  design  of  a  software  instrumentation  package  has  been  described. 
The  target  machine  initially  is  a  VAX  11/780.  However,  the  design  is 
applicable  to  pag ing/swapp ing  systems  in  general.  A  data  structure  for 
the  collection  of  information  is  given,  and  the  information  to  collect 
is  specified. 
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